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hitroduclion 



The present invention relates to a funds, transfer method and system. The invention 
paitidulariy relate to a fijnd transfer method in a system comprising a pIuraTity of entity 
oomputeis and a system server computer utteroonnected a communications 
netutforfc. 

Secure transfer of funds is required in many situations but particulariy in situations 
vwhere the parties are remote and do not meet face to face to complete a transaction. 
The transaction can be a very simple transaction, for example, a parent transfsning 
funds to a child in some other jurisdiction or transfemng funds to somebody else in 
anotiier jurisdiction or indeed at a remote location within the same Jurisdiction, the 
person transfening the funds and the person receiving the funds always have 
considerable problems as to" the security of the transfer. A further problem arises 
where there is actual trading taking place between a buyer.and seller. Very often, Une 
buyer has to transfer funds befbre the goods are received, thia seOer being obviously 
reluctant to.sentf the goods wittiout receiving; payment At*e same time, flie buyer is 
often unaware as to the merchantable qualHy of the goods being purchased, 
particularty where they have to be delivered, or indeed, as to the senrtce.-for example, 
vtfhere the senrfce can be delivered on Gne. There Is thus, ineffect, a reluctance for the 
buyer to twsl the seller to provide the goods or s^nrices to the quality and standard 
required and the seller is equally reluctant to provide those goods or sendees until he 
or she has been (iaid. This is a major problem where the buyers and sellers are 
unknown to . each oBier or where neiUier of them have an established trading or credit , 
reooni. internet auction sites are a particular «cample of this. 

There are many existing numbers of solutions to these problems such as those sold 
under the Trade Wlari<S PAYPAL. C21T and BILL PAY. The problem is that ti^ese 
systems suffer from a high level of disputes related to eitiier a commercial dispute 
■ between the parties or fraudulent activity by either of the parties. These disputes result, 
in high costs to ttte system to resolve them. The present invention is directed towards 
overcoming this. 



-2- . 
Statements of Invention 

The present invention relates to a funds transfer method in a system comprising a 
5 pluraRty of entity computers and a system sen/er. computer interconnected by a 
communications network. The system server computer has an escrow account 
associated therewith into and out of which funds may be transfen^d. The method 
comprises establishing, prior to or during a ftinds transfer, an errtity account for each 
entity computer with the system senrer computer Then, on a funds transfer being 
10 desired* t>elween two enjSty oornputers, designating, as appropriate, one as a remitter 
computer and the other as a recaver computer and then various steps are perfbmned. 
The remitter computer downloads the receiver ID to the s^tem server cpmputer, 
together with details of the transaction. The remitter computer then arranges with the 
system computer for funds to be available in an escrow account for transfer to the 
15 receiver entity account These funds are now no longer available to the renvtter 
computer. Then, on a specified event occurring, the remitter computer instructs that 
the funds being held available for the receiver entity account be released to the 
receiver entity account. Then,, funds are releaski to the receiver entity account 

20 In many situations, the system computer confnms the availability of funds in the escrow 
acxx)unt for the remitter entity accpunt to the receiver computer. This may be done by 
either the remitter computer or the system computer Very often, on the system 
Computer oonfinning the availability of funds in the escrow account the system 
computer sends a unique remitter tranMcKdn identifier to the remitter computer, 

25 usually two of thern, and the rerrttter computer sends one immediately to the receiver 
computer Then, liie receiver computer sends the Identifier to tiie ^stem server 
computer and the system server computer now has a matcti between the identifier and 
the receiver system computer account Then, on the specified event taking place, the 
second remitter transaction identifier is sent either by the remitter computer to the 

30 receiver computer which in turn sends this second remitt^ transaction identifier to ttie 
• system computer or directly by the remitter computer to the system corTv>uter to allow 
tifie release of the. funds. The manner in which tiie actual Identifiers are sent is a 
matter of choice. Needless to say, wherl there are goods or sen^ices involved, the 
second identifier will not be sent by tiie renutter computer, here a buyer computer, until 
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the remitler computer has received and acoq^ 

Detailed Description of <he Invention 

5 The invention will be more clearly understood finom the following description of some 
embodiments and ^mples thereof, gh/en by way of example only, with reference to 
the accompanying drawings, in which:- 

Rg. 1 is layout of a system in which the invention could be carried out; and 

10 

Figs. 2 and 3 are a flowchart of one method of carrying out the irwention- 

Refening to the drawings, there is provided a communications networtc 1 indicating a 
plurality of computeis, namely, entity computers 2 a[nd a system server computer 3. 
1 5 The ^stem sewer computer 3 h^ associated therewith a plurality c?f enti^/ accounts 4 
_and an escrow account 5. 

In operation and dealing firstly with a simple trading Nation between a. buyer and a 
seller where the buyer wishes to buy certain goods and the seller agrees to provide 

20 them, in this particular system, there is agreed an ariaitration system. Referring to Figs. 
2 and 3 there Is Blustrated a very simple layout of one trading operatfon. In step 1. the 
buyer agrees a price with the seller computer and in step 2, the seller provides a 
system account number to the buyer computer. Needless to say. this could be any 
other suitable reference other than an account nuniber such as an email address, 

25 trading code, and so on. The buyer, in step 3, lodges money or causes money to be 
transfened from the buyers entity account, if the buyer has one, or in any case, to an 
escrow account. In step 4. the funds are received in the escrow account and held in 
the escrow account These funds are not available to either the buyer or the seller 
computers at this stege. 

3Q 

• In step 5, tiie buyer receives two codes from the system server computer, namely, 
codes A and B. In step 6. the buyer sends code A to the seller computer. In step 7, 
ttie seller computer provides code A to the system server computer which locks the 
funds for the benefit of the seller, ttie seller computer then sends the goods to the 



buyer computer. In step 8, h»dng recehred code A which infoims the seller computer 
that the funds are being held In escrow, the sefler computer sends the goods to the. 
buyer. It win be appcedated that these could be simply services over the internet or the 
nke such as the downloading of music. In step 9, the buyer receiv^ the goods and 
5 the buyer then, in step 10, checks the goods. Presuming the goods are acceptable, 
then in step 11, the buyer sends code B to the seller. Then, in step 13, the seller 
sends code B to the system server computer and in step 14, the funds are transferred 
to the sefler account and in step 15, the buyer computer is infomrted that the tunds 
have been released from escrow to the seller account and in step 16 the transaction is 

10 complete. 

If, however, the buyer has not accepted the goods, then In step 12. the buyer enters a 
default date and then enters into negotlaHons and olher discussions with the selter and 
in step 17, the dispute has either been resolved or liot If it has been neteblvBd, step 1 1 

15 takes place and the remairider of the operaBon is as described above. If, however, 
this dispute has not been resolved, then step 12 is repeated by the buyer entering 
ariother default date. This rnay occur ^ fixed number of times, each time repeating 
steps 12 and 17 until either the. dispute has been resolved or not If it has not been 
resolved, then either the system Inffiates arbitration in step 18. flie art^tion is canied 

20 out In step 19, or the arialtratlon is conducted in step 20 which either means that the 
matter has been resolved satisfactorily between the buyer and seller and the 
remainder of the trade takes place. Thus steps 11, is; 14. 15 and 16 are carried out: 

If, hovwever. the arbitration, when concluded, does not mean that the trade continues, 
then in step 21, the transactfon is. cancelled. In step 22 the funds are released to the 
25 buyer and then step 16 Is carried out to end the transaction. As mentioned above, 
instead of using arbitration after a certain number of defaults, step 21 may take place 
without arbitraftton and the transaction canceUed. 



30 in its simplest, a buy/sell sHuation uses two codes and essentially a deal js agreed as 
In any situation, the seller provides the buyer with an. account reference nunnber, the 
buyer makes an escrow payment to the sellers account for the agreed value and the 
buyers account is in some way debited. If the partfcular buyer computer has an entity 
account already established, then that entity account Is debited. Alternatively, the 
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buyer computer ananges to transfer the fiinds to the escrow account. In the nomnal 
operafion of the account, the system wBI provide the buyer with two codes (codes A 
arid B) and geneialiy, ttie buyer wfll give one of these codes (»y. code A) to the seBer 
immediately via en^il, telephone or so on. Then, the seller calls up the trahsacfion 

5 wtthin his own account established with the system and enters this first code. 
Generally speaking, the system will transfer to tfie buyer, via en^il, that the seller 
computer has entered this first code. The funds are now in escrow and are not 
available to either party. The buyers account has indeed been debited but the sellers 
account has not been credited. Once ttie seOer has delivered the product or service as 

1 0 agreed, then the buyer gives the second code (code B) to the seller and the seller calls 
up the transaction withiri his system account or entity account and enters the code 
which then causes the system computer to release the funds and credit the account of 
the seller computer. Thus, the transacBon ends. 

15 Needless to say. when, for ©cample, the deal is concluded and the paymente have 
been made, the goods are delivered and the buyer dpes nothing further. Jhe second 
situation <»n arise where the buyer changes his or her mind, after msMng the payriient 
to the escrow account but before the seller has enteiBd code A and deBverekl ft to the. 
system computer. In another situation, either the delivery is not made, made partially or 

,20 the goods or sen/ices are unaccepteble: in this case, the buyer computer does not 
send the second code to the seller computer until the problem has been resolved. ; 

It is envls^ed that there are many ways in which the process rnay be carried out. For 
e)ample, when the, buyer computer initially sends tiie funds to the escrow account, a 
25 defeuK date may be entered whereby ttie seller Is notified that in the event of failure of 
the buyer to contact the server computer, the funds will be released, Effectively, this is 
a default date. Then, the system computer will autortiatically release the funds to the 
seller when this default date has passed unless ttie buyer computer has inten^ened. 

30 It.vylll be appreciated that the buyer computer can inten/ene in the process jn many 
* ways. Rrstly. the buyer computer could inten/ene before the seller computer has 
entered this code A. The buyer can then enter code A and cancel tiie transaction. 
The funds are returned to the buyer's account and the seller is infomned of a 
cancellation. This can only happen when the buyeir computer has received botii codes 
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and the seller computer has riot yet received code A which will be used as a tr^ger to 
supply the goods and services, ■merefoie. effectively, the whole operation Is cancelled 
prior to initiafon. 

5 . Before the default date, the buyer can enter code B that in ttiis case, releases the 
ftjnds immedfalely to the sellers account and thw the seOer would normally be 
infbmted. Alternatively, before the seller has entered code B and before the default 
date, the buyer can enter code B and defer the default date, for example, up to seven 
days. This Oaters for situations where a delivery has not been corrpleted or some 
10 discussion is taking place between buyer; and s^r and fime is rieeded to resolve ». 
The seller computer would then be notiffed oif the extertded default date from the 
system server ownputer. Weedless to say. thfe defe^fring. of the default date can be 
canfed out a number of times and it depends how many times are agreed, for 
example, in the system. It could, for example, nomrally be three. At some isfage. 
15 howewer, the buyer may enter code B with the resultent Immediate release of the 
fends unless some ftxm of dispute resolution has been initiated. This can either be 
initiated automaBcally or attemaHvely, can be initiated by a positive adtoh on behalf of 
the buyer computer. Needtess to say, orice this has happened, either the two parties 
can resolve K themselves or the transacSon can be referred to automatic dispute 
20 resolution and arbitration. 

The foVaw«ng are some examptes as to how the process according to the inventbn 
may t)e initialled. 

25 Example 1: 

1 . . The buyer provides funds, a default date and the seller account identifier to 
- the systerin server computer 

2. The system server computer provides code A and code B to tiie buyer 
30 3. The biver provides code A to the seller 

4, The selter provides code A to the system server computer,- which causes 
• the funds to be locked for the benefit of the seller. 



Example'2: 
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1 The buyer provides funds arid a default date to the system server computer 
2. The system server computer provides a transaction identifier, code A and 
code B to the buyer 

5 3. The buyer provides the transaction identifier and code A to the seller 

4. ' The seller provides the transaction identifier, code A and his account 
identifier to the system server computer, which causes the funds to be 
locked for the benefit of the seller. 

10 Example'3: . . 

The seller provides the details of the transaction including his account 
identifier to the system server computer 

The system server computer provides a transaction identifier to the seller 
The seller provides the transaction identifier to the buyer 
The buyer provides the transaction Identifier, funds and the default date to 
the system server computer 

The system server computer pmvides code A and code B to the buyer 
The buyer provides the code A to the seller 

The seller provides the.code A to the system server computer, which 
causes the funds to be locked for the benefit of the seller. 

In the event that the transaction is completed to the satisfaction of both parties there 
are three possible courses of actbn. 

The buyer provides code B to the system server computer with the instruction to 
refease the funds to the seller. 

The buyer provides code B to the seller. 

The seller provides code B to the system server computer with the instruction to 
release the funds to the seller. 

The buyer does nothing and the funds are released to the seller on the default 



1. . 
.2. 

t5 3. 

4. 

5. 
6. 

20 7, 



date. 



In the event ttiatttie transaction is not completed to the sat^cSon of the buyer. 

The buyer provides code B to the system server computer with the instruction to 
put back the default date. This may be done a number of times in order to provide 
a period of time to complete the transaction if it is talcing longer that expected or to 
resolve a dispute between the parties. 

Should it not be possible to resolve the dispute either within the maximum number 
of times the date can be put back or by the choice of the buyer, the buyer on 
providing code B to the System services computer may elect to send the dispute 
for arbitration. 

It will be apprecteiied that when there are funds oh^ being transfened beiween the 
parties without the dePivery of goods or senrices being a condition precedent therefor, it 
will be lebtively simple for one computer to transfer to another entity computer, by 
simply downloading receiver ID and receiving a code from the system sen/er computer. 
Until the receiver computer had been infomned by the system sender computer that 
ttiere were funds available, the funds would be kept in escrow. Once the. receiver 
computer had Identified thd funds wers available and they wers available for him or 
her, then the receiver conriputer can inform the renutter computer and the remilter 
computer can then, dispatch a code, either itself to the system siien/er or to the receiver 
oonriputef lor onward transmisston. In this way, the remitter can be confWent that the 
funds are being defivered to the right person. 

The innovative feature of the invention can be surhmarised as follows: 

1 . The remitter provides funds to the escrow account 

2. The system sen/er gives the two codes to the remitter 

3. Until the receiver enters tiie first code, these funds may be retrieved by ihe 
. rerrutter 

4. The receiver gets code A and he provides this to the system server 

5. -The funds are now locked to the benefit of the receiver but he cannot 
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aoctes these funds until code B has been provfded 

6. An event occurs that concludes the transaction (goods are received by the 
nentitter) 

7. Provided ttie remitter Is happy, he provides code B to the receiver 

8. The receiver then enters code B and he then has access to ttie funds. 

The above Is the simple situation with no problems. 

However, when a problem aris^, one vway of solving it, described herein, can be 
summarised as foDows: 

1. The renrtftler is no happy with the goods . 

2. The remitter may enter code B arid signal the existence of a problem to 
the system sen/er and the sen/er or remitter will select a date by which 
the problem should be resolved 

3. The system server infomts the receiver (or not, as the remitter may do 
this) of this action by the renrtitter (this provides a breathing space for 
the two parties to sort out the problem) 

4. The remitter wfll be pemiitted a fixed number of time that flie deadline 
date be extended 

5. • Only after the parties have feiled to resolve tiie problem ttierinselves, 

does this sj^tem stert the arbitration process. 

In the specification ttie temns "comprise, comprises, comprised and comprising" or any 
variation fliereof and tt^e tenns "include, includes, included and including" or any 
variation thereof are considered to be totally interchangeable and ttiey should all be 
afforded the widest possible interpretation and vice versa. 

The invention is not limited to the embodiment hereinbefore described but may be 
varied in both construction and deteil. 
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